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Background Of Invention 

Field of Invention 

The present invention relates to an improved method of and system for mitigating 
payments risk, liquidity risk and systemic risk in the settlement of foreign exchange transactions 
and many other payments-based transactions. 

Brief Description of Prior Art 

Payments made through large value payment systems in all currencies globally total more 
than $4 trillion a day in average values. These payments are made up of individual payment 
transactions relating to specific underlying payment obligations incurred through trading in 
foreign exchange and financial markets, commercial lending operations, and trade in goods and 
services. Payments are all effected through the domestic payment systems operated within each 
currency area. 

Participation in payment systems is generally limited to larger banks. Participant banks 
make payments to one another in these payment systems and other market participants, smaller 
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banks and foreign banks will hold accounts with participant banks to effect payments on their 
behalf. 

"Payment risk" arises in any case where one financial market participant makes 
payment(s) to another finmicial market participant in expectation of later receipt of other 
payment(s) in return, whether in connection with the same or different financial transactions. 
The expected receipt of payment may be in the same currency or in a different currency. 

Failure to receive expected payments from a financial market counterparty or his 
intermediary - whether arising firom operational causes such as computer failure, financial causes 
such as illiquidity, or legal causes such as bankruptcy - can cause substantial harm to financial 
market participants. They will suffer the effects of an unexpected shortfall equaling the amount 
of the failed payment. In the best case, tWs will unposes costs associated with borrowing or 
fimding the amount of the shortfall, and in the worst case may cause contingent failures to pay 
their own obligations which were dependent on receipt of the expected funds. The ease with 
which ilUquidity and loss of confidence can spread in financial markets itself creates the risk of 
system-wide disturbances from a single payments failure, known in the industry as "systemic 
risk". 

The single greatest component in payments traffic is settlement of payment obligations 
arising from foreign exchange trading. The foreign exchange (FX) markets in our world trade 
over $1 trillion worth of capital currencies daily. Economic order throughout the global banking 
system generally requires that parties engaging in such foreign exchange transactions make 
payments due thereunder in a timely manner to prevent default and the consequences associated 
therewitii. 

As shown in Fig. 1, the conventional method of making payments in connection with 
foreign exchange transactions, takes place over a standard 3 day cycle. On the Trade Date, 
various foreign exchange transactions are dealt either by telephone or electronic execution 
system between a User of the GPM system and a market counterparty. This is followed by the 
exchange of MT300 messages, in a prescribed industry data format, via a global bank 
communications network maintained by the Society for Worldwide Inter-bank Financial 
Transmissions (S.W.I.F.T). This global bank communications network, commonly referred to as 
the SWIFT network, is a proprietary value added network (VAN) which use electronic data 
interchange (EDI) message fomiat standards. The Intemational Standards Organization (ISO) 
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recognizes S.W.LF.T. as the organization responsible for the promulgation and maintenance of 
these message standards within the global banking industry. 

Once the MT300 messages are matched in each party's back office, each party generates 
a payment instruction for the sold currency and a pre-advice for the bought currency to a bank's 
own branch, or a correspondent bank holding an account for the bank in a foreign currency. 
Where banks make payment using correspondent banks, they undertake payment for their own 
account, whether or not they are involved in an underlying transaction as principal or agent of a 
non-bank market participant. The message types most important to payments include the MT200 
for own account payments, MT202 for general commercial payments, and MT210 Pre-advice of 
expected receipt of funds. 

The correspondent bank uses the S.W.LF.T. network to confirm transactions in an 
account back to the account holder. The most important messages for this purpose are the 
MT900 advice of debit to account, MT910 advice of credit to account, and MT950 statement of 
daily account activity. In short, correspondent banking is a mechanism used by banks to effect 
payments in currencies other than their own. 

All payment message types reference the paying bank, the account holder (if any), the 
receiving bank, the counterparty account holder (if my\ and the Transaction Reference Number, 
a unique number identifying the underlying transaction using the prescribed industry data format. 
Messages to correspondent banks are sent using the S.W.LF.T. network. Messages in domestic 
payments systems are sent using the network facilities and formats prescribed by the individual 
domestic payment system. 

Payments within domestic pajment systems are currently managed by the construction of 
a queue of payments messages for a particular day within a bank directly Unked to a domestic 
payment system. Liquidity management software is used to control the flow of payments 
messages from the queue into the domestic payment system for clearance, to monitor balances at 
the central bank, and to monitor payment conditions vis-a-vis other directly participating banks. 
The liquidity management software allows payments to proceed according to the priority of 
individual payment messages and the liquidity available in the system. 

Settlement Date is normally two business days after Trade Date for spot transactions in 
foreign exchange, and can be much later for forward transactions. On the Settlement Date, each 
branch of a bank operating the link to the domestic payment system for a currency, or each 
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correspondent bank acting as a nostro for other banks* payments in a currency, will construct a 
payments queue containing all the messages requiring payment on that date. 

Where the payments are to be made via a real-time gross payment system or other system 
accommodating payment instructions on a real-time (as opposed to batch process) basis^ the 
payments are released one by one as sufficient liquidity in the clearing account of the bajok 
permits. Liquidity management software is used by banks connecting to these systems to keep 
track of the balance in the clearing account within the payments system and release payments as 
liquidity permits. Also, such software will generally ensure that sufficient balance or credit 
exists in the account of the accoxmt holder to cover the payment. Such software shall hereinafter 
be described as "liquidity/payments manager." Payments made from the queue reduce the 
balance, while payments received from other banks in the system increase the balance. The 
process continues until all payments on the queue are sent. 

Banks acknowledge payments and receipts to their correspondent banking account 
holders using the S.W.LF.T. network, and to non-bank account holders using vmous methods. 
For correspondent banks, an MT900 is sent following debit of a payment from a client's account 
An MT910 is sent following credit of a received payment to a client account. At the end of the 
day, an MT950 statement of account activity is sent to confirm every debit and credit through the 
account during the day, and the opening and closing balances, using an industry standard data 
format. 

The Reconciliation Date is normally the day following the Payment Date. Institutions 
active in the foreign exchange markets typically take all the MT950 statements from all branches 
and correspondent banks acting on their behalf for settlement, and provide fliese statements as 
inputs to a batch process for reconciliation. This process determines whether for each payment 
made in respect of a trade, whether a counterpayment was duly received as expected. If payment 
has been made, but no counterpayment received, then the party is at risk for the gross amount of 
the payment as an unsecured creditor of the counterparty. An exceptions report is generated as a 
result of the reconciliation batch process, which is used for querying missed payments with 
counterparties, generally by telephone. Only after a query (often made difficult by geographical 
distance and time zone differences) can a decision be made about the credit- worthiness or 
potential default of a counterparty. As a result it can be two or three days following missed 
payments before a counterparty is declared in default and further payments are suspended. As a 
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result of this process overall, the risk to a foreign exchange market participant, arising because 
payments are typically instructed on a transactional basis (as obligations are incurred) and are 
processed independent of other transactions which would result in expected receipts, may be as 
much as three days gross value of payments to a counterparty. This risk is known as "cross- 
border settlement risk" and is a variety of the broader category of "payment risk". 

Payments risk may well exceed the capital of a bank or other financial institution, raising 
a potential that a counterparty failure could cause their own insolvency, arising from the 
difficulty that financial institutions are likely to have raising fimding rapidly to cover a shortfall 
should expected receipts fail to materialize on the payment date. This risk is known as "liquidity 
risk". 

Liquidity risk, in turn, may perpetuate a systemic impact throughout the chain of 
counterparties active in the financial markets, arising from payment failure due to liquidity 
problems, through a chain of co-dependent payments transactions. This risk is known as 
"systemic risk" and is a principal concem of central bankers and supervisors in overseeing the 
strength of capital markets. Payments risk, liquidity risk, and systemic risk associated with 
participation in payments systems are sunmiarized in the table of Fig. 2. 

Cross-border settlement risk in the foreign exchange markets has been exacerbated by 
recent trends in the markets. Many smaller participants now trade directly in the markets 
through electronic foreign exchange trading systems. The past five years have seen the market 
share of the top dealing banks fall fi*om approximately 60 percent of the market to less than 40 
percent of the market, demonstrating theii* displacement by more active smaller institutions. 
These smaller institutions tend to have lower credit ratings, and so present higher levels of 
payments risk to their counterparties. Additionally, there has been a shift toward increased 
trading volumes in the currencies of emerging economies. These currencies are generally less 
liquid and more volatile, particularly in conditions of general market uncertainty, and so present 
higher liquidity risk and systemic risk in the event of a financial failure. 

In addition, there has been a movement toward more rapid settlement of transactions, 
with some transactions now settling on the same day as trading or the next day, as opposed to the 
customary two days following trade date. The shorter settlement times put pressure on banks 
involved in payments as they increase uncertainty as to liquidity, and are often inconsistent with 
existing systems for trade processing and reconciliation. 
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Hitherto, a number of prior art systems and methods have been proposed for mitigating or 
managing the various types of risk associated with making payments in connection with foreign 
exchange transactions in our global financial capital market system. 

One proposed method of managing payment risk involves the "contractual netting" of 
payment flows, whereby parties agree to net all payment obligations for any given date and only 
effect net payments to one another. 

Contractual netting requires that both parties sign an enforceable legal agreement to net 
their obUgations, that the parties agree daily the specific amounts of the payment flows in 
setdement of transactions, and that the paities maintain systems for the reconciUation of 
payments against transactions to ensure that underlying transactions have been settled. 
Supervisors generally require independent legal opinions supporting netting enforceability before 
conferring any benefit of risk reduction for capital adequacy purposes. In consequence of its 
complexity and legal uncertainty in many countries, contractual payments netting embraces only 
one-quarter of transactions in foreign exchange markets. 

In connection with the above method of risk management, a system referred to as 
FXNET exists for tiie calculation of bilateral netting exposures and net payment amounts in 
traded currencies for its participants. This system is designed to reduce the operational 
complexity of bilateral netting on a daily basis as between its users. It has less than 100 bank 
users. 

In addition, two other systems have been proposed for providing multi-lateral netting, or 
clearing house, operations to the foreign exchange markets. The first system is the MultiNet 
system which never became operational, and was abandoned in late 1996. The second system is 
the Exchange Clearing House (ECHO) which was operational for several years, but operations 
were suspended in 1998 because they were deemed uneconomic. 

CLS Bank has proposed an altemative method of managing risk in connection with 
foreign exchange transaction payment systems. This method involves developing a 
clearinghouse which seeks to provide a tiered system for clearing foreign exchange settlements, 
ending with value-for-value settlement of foreign exchange transactions through the agency of a 
special purpose bank with accounts at participating central banks. CLS Bank's clearinghouse is 
only effective for transactions wholly in tlie currencies admitted to the system (i.e. 7 currencies 
are proposed for initial operations), only market participants joining the CLS system or clearing 
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through particip^ts, and only for foreign exchange settlements. The CLS system requires 
substmtial investment and changes to existing systems for reportmg and matching of 
transactions, and for payment and liquidity management among participants. Even if CLS Bank 
were to settle all eligible foreign exchange trades for all its 60 shareholder banks, this would only 
address the risk on 27 percent of foreign exchange market transactions. 

Although the foreign exchange markets account for the single greatest proportion of 
payments, they represent only about half of all payments by value. Banks assume risk on one 
another in domestic payments systems for all their payment transactions with one another. The 
risk arises because payments are generally made and received through domestic payments 
systems without regard to the payment imbalances which may accrue between any two payment 
intermediaries or accoimt holders. 

Hitherto, a number of prior art systems and methods have been proposed for mitigating or 
managing domestic payment risk associated with making payments in domestic payment 
systems. 

One proposed method of managing payment risk involves the netting of payment flows 
throughout the operating hours of a payment clearing house, with settlement of the net balance 
by transfer of funds periodically during tlie day or at the end of the day. Participating banks 
agree with one another contractually to net all payment obligations for any given date as 
payments are processed by the clearing house. This method requires both banks involved in a 
payment to be participants of the clearing house and to route payments through the clearing 
house. 

A bank participating in a net clearing house for payments processing will incur a payment 
risk exposure on any other bank participant for the net imbalance of payments in its favor 
pending actual transfer of the funds in setdement of the net payment obligation. Some clearing 
houses impose bilateral net debit caps on their bank participants to limit the amount of exposure 
thus assumed during the day. Others additionally provide coUateralisation, guarantee or loss- 
sharing schemes which contractually allocate the losses which may arise in the event that a 
participant's default on its net payment obligations. 

Real-time gross payment systems provide for the real-time transfer of cash balances on 
the books of a central bank, providing instant finality of payment in cleared fimds. Banks 
participating in these systems must have cash balances available with the central bank to cover 
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payment instructions, or have secured overdraft or collateralised lending facilities to cover any 
shortfall. Real-time gross payment systems therefore create greater pressures on liquidity during 
the business day, as payments may be blocked from timely processing due to inadequate 
liquidity. Each bank will be dependent on the payment performance of other banks for the 
liquidity required to enable release of payments, with disruption transmitted very rapidly 
throughout the system in the event of a persistent payment failure by any one participant, 
whether due to operational or credit conditions. 

Overdraft and collateralised lending facilities are the principal methods for managing 
intraday liquidity demand in real-time gross payment systems. Overdraft facilities expose a 
central bank to the risk of loss in the event of a payment failure, so are generally limited in 
amount and only available in some few currencies. Collateralised lending facilities require the 
posting of securities, typically government bonds, as collateral for overdraft facilities in the 
payment system. CoUateralisation creates an added expense for bank payment processing and a 
drain on the Hquid securities available to the participating bank to pursue other business. 

A further variation of domestic payment systems arises in some systems where individual 
banks are very dominant. These banks may hold accounts for a substantial portion of 
conmiercial and financial entities making payments in tiie currency, and may therefore be in a 
position to accomplish payments on behalf of account holders by transferring balances between 
accounts on their own books without recourse to domestic payment channels. These so-called 
"book transfers" should be considered a fiarther payment channel, but are govemed by the rules 
created by the bank itself. 

Whatever the nature of a payment, in the case that a financial market participant is not 
itself a direct participant in a payment system, it will rely on a bank as intermediary to effect the 
payment on its behalf through an account with the bank. In such cases, the account holder has 
very limited control on the timing of the payment and the risk it may incur on other payment 
counterparties or intermediaries in the currency. 

The only method currently available to account holders for control of payment risk today 
is the withholding of payment instructioas until confirmed receipt of expected payments is 
recorded. This process, used by only a handful of market counterparties in a handfixl of 
currencies, creates a systemic illiquidity problem. The withholding of payments by these few 
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indirect participants impairs the liquidity available to their payment counterparties, and by 
extension the payment system as a whole. 

All payments transactions to financial market participants who are not direct participants 
in a domestic payment system will involve one or more intermediary banks in the chain of 
accounts to the ultimate payment beneficiary. Payment risk will arise on these intermediary 
banks as payment to the ultimate beneficiary is dependent on their performance. For this reason 
it is important to be able to separately identify and control risk on financial institutions as 
payment intermediaries* 

In summary, prior art methods of and systems for managing risk in connection with FX 
and other payments transactions throughout the world suffer from the following shortcomings 
and drawbacks: they require agreement of the transaction counterparty; they do not extend to 
non-bank counterparties; they are complex and difficult to implement; and they do not 
adequately enable a typical foreign exchange or other market participant to control the risk 
arising in respect of the plurality of its coimterparties, currencies and payment types. 

Consequently, there is a great need in the art to provide an improved method of and 
system for mitigating risk associated with participation in payments systems involved in settling 
foreign exchange and other financial transactions. 

Objects of the Present Invention 

Accordingly, a primary object of the present invention is to provide a global computer- 
based method of and system for mitigating risk arising in connection with foreign exchange 
settlements and other payments between financial market participants, while avoiding the 
shortcomings and drawbacks of prior art methodologies. 

Another object of the present invention is to provide such a system, wherein the control 
of payments risk is efficiently enabled in as many currencies as may be interoperable with such a 
system. 

Another object of the present invention is to provide such a system, wherein the control 
of payment risk is efficiently operated for a plurality of payment systems in each currency, 
mcluding book transfers in settlement of payment obligations within a single bank. 

Another object of the present invention is to provide such system in the form of a real- 
time Intemet-based method of and system for controlling payment flows in a way that reduces 
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payment risk between financial market participants, both within a single domestic payment 
system and globally through a multi-currency implementation. 

Another object of the present invention is to provide such a system as enables financial 
market participants to control such payment risk on one another whether such risk is proprietary 
to a counterparty on a transaction or arises as a result of financial intermediation in the payment 
process. 

Another object of the present invention is to provide such a system as enables the control 
of payments risk arising for a financial institution or an account holder within a single currency, 
as well as cross-border payments risk arising fi-om payments in a plurality of currencies. 

A further object of the present invention is to provide a computer-based payment risk 
management system to enable control of payments risk for all payment flows, whether arising 
fi-om foreign exchange transactions or other payment types. 

Another object of the present invention is to provide such a system as enables a 
participant to unilaterally control his risk vis-a-vis a particular financial markets participant, 
without the necessity for agreement or cooperation of the other institution. 

Anotiier object of the present invention is to provide such a system as allows participants 
to more efScientiy manage tiiek current busmess, reduce overhead, improve returns on capital, 
and support new busmess with counterparties by reducing payments risk and enabling more 
efficient liquidity and credit risk management. 

Another object of the present invention is to provide such a computer-based system and 
software tiiat can readily be used by all financial market participants, from money-center banks 
to corporate end-users worldwide. 

A fiirther object of the present invention is to provide a computer-based payments risk 
reduction system which does not require substantial change to the conventional market ti-ading, 
confirmation, matching, clearing, instinction and reconciliation as developed to support financial 
market transactions and correspondent banking. 

A fiirther object of the present invention is to enable each financial institution or 
corporate hierarchy to determine the optimal allocation of system access, such that any 
individual branch, subsidiary, company or other legal or organizational entity can have separate 
access. 
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A further object of the present invention is to provide a computer-based system in which 
separate accounts can be flexibly aggregated or disaggregated by participants for risk 
management and reporting purposes to promote effective oversight of group or individual 
participant use of the system. 

A further object of the present invention is to provide a computer-based system in which 
separate financial market participants can be flexibly aggregated or disaggregated for risk 
management purposes and reporting purposes according to participant assessment of risk 
correlation between affiliated, connected, geographically co-located or similar financial market 
participants. 

A further object of the present invention is to provide a computer-based system in which 
payment flows with a financial market participant or participants in a plurality of currencies and 
payment systems can be flexibly aggregated for risk management purposes and reporting 
purposes. 

A further object of the present invention is to provide a computer-based payments risk 
reduction system that is consistent with and complementary to the existing network for inter- 
bank financial commimications (S.W.LF.T.), domestic payment messaging standards and the 
intemet protocol networks increasingly used by financial institutions. 

A further object of the present invention is to provide a computer-based payments risk 
reduction system which does not require information details regarding the underlying 
transactions on which the system acts to reduce payments risk. 

A further object of the present invention is to provide a computer-based payments risk 
reduction system which allows individual participants to determine unilaterally their tolerances 
for payment risk according to financial market participant, currency and payment t3^e. 

A fiuther object of the present invention is to provide such a system in which participants 
can view, enter and alter their risk parameters for financial market participants, currencies and 
payment types on a real-time basis. 

A further object of the present invention is to provide such a system in which the risk 
parameters set by participants can be entered into the database of the system by way of screen- 
entry, batch-entry or integration with internal systems processes. 
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A further object of the present invention is to provide such a system in which payments 
risk can be controlled in an automated manner through integration with the existing payments 
systems operating within payment banks directly connected to domestic payments systems. 

A further object of the present invention is to provide such a system as enables payment 
banks to integrate the system host application in a modular fashion in connection with their 
participation in domestic payment systems with a high degree of openness, flexibility and 
interoperability, 

A further object of the present invention is to provide a quicker and easier means for 
monitoring payment flows and reporting exception situations which may indicate a financial 
market participant's payment failure. 

A further object of the present uivention is to provide a computer-based system for a 
payment bank to notify account holders of payment problems intra-day, enabling them to take 
such actions as will forestall and mitigate adverse impact on liquidity in that and other 
currencies. 

A further object of the present invention is to provide a quicker and easier means for 
inquiries into exception situations between and among participants and payment banks, 
facilitating earlier corrective action or remedial action as appropriate. 

A further object of the present invention is to provide a computer-based system for account 
holders to notify payment banks in real-time of their wish to suspend any further payments 
identified financial market participants or intermediaries. 

A further object of the present invention is to provide tiie computer-based system 
capability within a payment bank to efficiently and effectively suspend any further payments to 
financial market participants or intermediaries on behalf of m account holder, following receipt 
of a request fi-om an account holder to do so. 

A further object of the present invention is to provide a computer-based system enabUng 
automated calculation of global risk positions based on payments activities in multiple payments 
systems. 

A further object of the present invention is to provide a computer-based system which 
integrates the advantages of Web-based information management, browser interfaces, 
application-to-application data interchange, object-oriented programming and open systems 
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technologies to deliver improved flexibility, extensibility, modularity, interoperability and other 
information management advantages in connection with pa5anents risk management. 

A further object of the present invention is to reduce or eliminate the systemic risk that a 
payment failure by one financial market participant or intermediary may lead to failure of 
contingent payments down a chain of interrelated payments transactions, and thereby threaten 
the liquidity and integrity of payment and banking systems within a single market or globally. 

A further object of the present invention is to provide such a system, in which a 
participant's payments liquidity is more optimally used to meet payment obligations in an 
automated manner. 

A further object of the present invention is to provide such as system in which liquidity 
management software is employed to address cross-border payment risk or payment risk arising 
on the level of the individual account holder within a participating bank. 

A further object of the present invention is to provide such a system in which payment 
instructions can be processed very rapidly after negotiation of the underlying trmsaction without 
compromising payments risk mitigation. 

A further object of the present invention is to provide such a system as enables access via 
a plurality of intemet protocol networks md a plurality of computing devices, and flexibility in 
the use and configuration of access software to meet individual functional requirements and 
capacity to support technological integration. 

A further object of the present invention is to provide such a system in which many-to- 
many data processing rationalizes the flov^s of information between host applications located 
anywhere ^oimd the globe (in both developed and emerging markets) without the prejudices and 
disadvantages arising from geographical dispersion. 

A further object of the present invention is to provide such a system in which payment 
risk parameters and other data entered into the system are automatically interpreted by rule-based 
interpretation procedures as to processing requirements. 

A further object of the present invention is to provide such a system in which account 
holder payment parameters are managed on a database and communicated as operable 
parameters for payments processing by host applications in payment banks. 
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A further object of the present invention is to provide a system which uses or 
interoperates with industry standard data formats for tiie capture and transmission of like data to 
enable efficient interface with pre-existing banking applications and systems. 

A further object of the present invention is to provide a system which provides 
appropriate security and integrity for the transmission of all data across its network via 
cryptographically secure sessions and digital certification of host application subscribers. 

A further object of the present invention is to enable payment risk control against a 
financial market participant whether it is the ultimate beneficiary of a payment or an 
intermediary in the payment process acting on behalf of the beneficiary or other intermedimies. 

A fiirther object of the present invention is to serially assess a payment which will pass 
through one or more intermediaries for compliance with risk parameters set independently for 
intermediaries and the ultimate payment beneficiary. 

A further object of the present invention is to enable account holders to instruct the 
override of payment risk filters for particular payment transactions or payments to or through 
identified financial market participants or intermediaries, 

A fiirther object of the present invention is to provide automated implementation of 
overrides to enable payments to bypass payment risk filters as instructed by an account holder. 

A fiirther object of the present invention is to enable accoimt holders to set risk 
parameters which will take effect in default of specific instructions. 

These and other objects of the present invention will become apparent hereinafl:er and in 
the Claims to Invention. 

Summarv of the Present Invention 
According to one aspect of the present invention, a Global Payments Management 
(GPM) system and method are provided for the purpose of tying together Third Parties, Users 
and Payment Banks sites (in the United States, Europe, Asia and other locations throughout the 
world) via a global communication network (e.g., interconnected internet protocol networks and 
a virtual private network) to enable Third Parties and Users to communicate payments risk 
controls and other instructions to Payment Banks making and receiving payments on their behalf, 
to facilitate real-time communications system-wide, and to provide more timely and better 
quality information on payments risk management. 
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In order to support Third Parties, Users and Payment Banks located in different time 
zones, the GPM System preferably is available 24 hours a day and seven days a w^eek. Such high 
availability allows Third Parties, Users and Payment Banks to participate in the system in a 
substantially equal manner, overcoming tlie disadvantages of remote location inherent in foreign 
exchange trading and settlement. The system takes advantage of advances in Internet Protocol 
(IP) networks, Web-based programming and electronic data mterchange (EDI) techniques to 
ensure its compatibility with the plurality of existing operating systems, legacy software mi 
participants' levels of technological sophistication. The system can be used by all market 
participants, large and small, who wish to reduce the payment risk exposures arising from their 
participation in foreign exchange markets and/or improve the risk and liquidity management 
associated with their domestic and international payments generally. 

"Third Parties" potentially include all financial and commercial entities involved in 
payment flows (for example, substantial wholesale payment flows in the FX markets) as account 
holders with a User bank or non-bank financial institution. 

"Users" potentially include all banks and non-bank financial institutions instructing 
pajnnent on their own behalf or as correspondent on behalf of Third Parties, and all financial and 
commercial entities as account holders in a domestic payment system. Third Parties in a cross- 
border context may simultaneously be Users in a domestic context. 

"Payment Banks" potentially include all banks and non-bank financial institutions 
responsible for making payments on behalf of Users as part of the payment process in a 
payment-based transaction, and may be directly linked to a domestic payment system. Users 
may shnultaneously be Payment Banks for one or more currencies. 

"Coxmterparties" potentially include all financial market participants who transact with 
Users mid Third Parties to create payment obligations or serve as intermediaries in the payment 
process by holding accounts on behalf of payment beneficiaries or their financial intermediaries. 
The GPM System of the present invention will enable Users and Third Parties to flexibly 
structure identification of Counterparties to aggregate or disaggregate affiliates within a 
corporate group or branches of a financial institution, or to group Counterparties with similar 
nationality or other risk factors. 

The GPM System of the illustrated embodiment supports the following functionalities: 
Third Party and User host applications for screen, batch and automated entry of payment risk 
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parameters by currency. Counterparty and payment type; a core system host application for 
automatic rule-based sorting of parameters according to Payment Bank acting on behalf of Users 
for payments in a particular currency and/or to a particular Counterparty; communication of 
parameters to the Payment Bank host application controlling payment flows to the domestic 
payment system(s); automatic rule-based Filtering within the Payment Bank host application of 
payment messages against User-specified payments risk parameters to ensure continuing 
compliance with parameters; real-time notification of exception conditions from the Payment 
Bank to the User (e.g., to indicate Counterparty payment difficulties); real-time communications 
messaging between Third Parties, Users and Payment Banks to facilitate inquiry into and 
resolution of exception conditions; ability for Third Parties and Users to override the filter in the 
Payment Bank host application by transaction reference number or Counterparty identification; 
ability for the Payment Bank to manually override the Payment Bank software to enable a 
payment to proceed notwithstanding non-compliance with parameters; ability for a User to 
instruct the Payment Bank to suspend any further payments to a particular Coxmterparty; ability 
for Payment Bank host application to stop any further payments to any Counterparty; ability to 
flexibly generate a variety of reports periodically or on request according to the requirements of 
Third Parties, Users and Payment Banks; secure, reliable and encrypted communications; and 
accommodation of multiple Third Parties, multiple Users, and multiple Payment Banks at 
multiple geographical locations. 

In accordance with the illustrative embodiment of the present invention, Third Parties 
have pre-existing account relationships with Users such that Users transact payments in one or 
more currencies on their behalf Users (who may act on behalf of Third Parties) are institutions 
possessing a Bank Identifier Code (BIC) as published by S.W.LF.T., a universal standard 
identification method recognised by the ISO. The BIC is a xmique address which, in 
telecommunication messages, identifies precisely the financial institution involved in financial 
transactions. 

Users have pre-existing account relationships with Payment Banks such that Payment 
Banks transact payments on their behalf in one or more currencies. Banks or branches acting as 
Payment Banks for a User are identified by their BIC. 

The GPM System has five principal component parts: a GPM Network, a Third Party 
Host Application, a User Host AppUcation, a GPM Core System and a Payment Bank Host 
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Application. The GPM Network is a network of commercial and privately operated IP networks 
interlinked to the GPM Virtual Private Network (GPMA^N) using routers. The GPMA^PN, 
operating with controlled access, cryptography and firewalls^ will ensure superior security, 
integrity and resiliency for the GPM System, 

The customer account structure within the GPM System is deliberately flexible as to 
organization and number of customer accounts for any given corporate entity or affiliated group. 
Banks, for example, may choose to assign each branch dealing in the markets for its own account 
a separate User status within the GPM System, or alternatively may wish to centralise control m 
a single branch through assigning other branches the status of Third Parties. Corporate treasuries 
may similarly disaggregate corporate divisions as Users with their own accounts, or aggregate 
them as Third Parties under a single User account. Regardless of account structure, the GPM 
System enables accounts to be Unked together for reporting purposes in flexible hierarchies of 
User and Third Party accounts, according to whatever configuration a User may require. 

Throughout the preferred embodiment of the GPM System, its sofltware components are 
created using the Java™ programining language, its data format protocol expressed in the 
extensible Mark-up Language (XML), and its human-machine interfaces realized using Web 
(http) browser interfaces enabling human users to interact with the system. The Web-based 
architecture of the GPM system has significant advantages in terms of flexibility, openness, 
interoperability and maintenance, in particular enabling flexible publication of information and 
software upgrades, interoperability with a wide variety of pre-existing technology platforms, on- 
line application interaction and commimications system-wide, and other processes related to 
Web-based and distributed computing. 

Preferably, network interconnection between Third Parties and Users will be jointly 
determinated. Third Parties communicate their risk parameters and other payment-related 
information to Users. Only Users can pass risk parameters or payments-related information 
through to Payment Banks, as only the account holder (the User) can properly instruct a bank 
(the Payment Bank) as to actions affecting an account. 

The Third Party Host Application is realized as software provided to Third Parties as 
clients of Users at multiple sites located globally. The software components of the GPM system, 
including the Third Party Host AppUcation, can be downloaded from a Website on the World 
Wide Web (WWW) or delivered on compact disk with or without payment of a fee. Various 
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instances of the Third Party Host AppUcation may be available to cater for differences m 
language, financial m^kets activity, and relative technological and financial sophistication of the 
plurality of Third Parties, The Host Application enables a Third Party to request that a User 
bank generate processes in the GPM System reflecting the expressed preferences of the Third 
Party with respect to risk management, messaging and reporting. Whether the User is required 
to implement these requests through the GPM System will be a matter for joint agreement 
between the User and the Third Party, Third Party access to Users and the GPM System may be 
through manual input, batch input or automated application-to-application data mterchange. 
Preferably, the Third Party Host Application also supports inquiries, reports and messaging 
similar to the User Host Application. 

The User Host Application is realized as software provided to Users of the GPM system 
at multiple sites located globally. Various instances of the User Host Application will be 
available, to cater for differences in language, financial markets activity, and relative 
technological and financial sophistication of the plurality of Users big and small. At the simplest 
instance in the illustrated embodiment, a browser interface to the User Host Application will 
enable any small User with the capability of launching a commercially available browser to 
access, manually input to and use the GPM System. For those Users with moderate complexity 
(perhaps regular participants in the foreign exchange markets but not dealers themselves) an 
instance of the User Host Application will additionally provide facilities for file upload fi-om 
commercially available spreadsheet programs using commercially available software for data 
translation. At tiie most sophisticated level, for Users who are dealers in the foreign exchange 
markets or commercial or investment banlcs, the User Host Application can integrate with pre- 
existing transactions systems in the middle and back office using data mapping and electronic 
data interchange fimctionahties. 

On a periodic (usually daily) or real-time basis, the Users of the GPM System determine 
their tolerance for loss in respect of each counterparty or intermediary in each currency as 
payment risk parameters for GPM processing, either on their own account or on behalf of Third 
Parties. The basic parameter is preferably a clean payment limit (which may be set to zero). 
Users may also set default risk parameters to control risk in the absence of receipt of a periodic 
instruction. Users may alter risk parameters at any time. Preferably, GPM Users have the option 
of applying risk parameters to Counterpanty payments according to message type, so that the 
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GPM System can address payment risk either for own account transfers (MT200) and 
commercial payments (MT202) in a cross-border context, and other categories of payments 
arising in domestic payment systems. 

In the illustrative embodiment of the present invention, the Third Party and User Host 
Application access the system using commercially available Web browsers supporting 
extensible Mark-up Language (XML). The XML data protocol is extremely useful as it is 
capable of support for human-to-machine and machine-to-machine mteractions. This provides 
tremendous flexibility for human interaction with the GPM System as the Third Party or User 
Host Application can therefore be accessed from any workstation or other device capable of 
launching a browser and accessing the installed software via telecommunications. This has 
advantages particularly for banks or companies with geographically dispersed operations, as 
various offices can access a single instance of the Third Party or User Host Application installed 
at a central site. Alternatively, an executive travelling from his office may still be able to access 
the Third Party or User Host Application via telecommxmications link into the office's internal 
systems. 

The "risk parameter" data files are transmitted to the GPM system via IP networks 
interlinked by routers to a GPM Virtual Private Network (GPMA^PN). The GPMA^PN provides 
improved facilities for ensuring the security, integrity and resiliency of the telecommunications 
network. The network structure offers flexibility as well, as the GPMA^PN can be interiinked 
via routers to commercially available internet networks (e.g., ATT, Sprint, BTSyntegra, Equant, 
IBM), virtual private networks owned by banks or consortia (e.g., VPNs operated by Reuters, 
Bloomberg, S.W.LF.T.) and even the Internet. 

Once the GPM has received risk parameters or other messages from a User, the GPM 
Core System stores the input in the Data Server and processes the input in the Process Server. 
Data changes and messages will be sorted according to recipient using rules-based processing 
acting on the data fields in the files and messages. New data files are generated containing risk 
parameters for action by a single Payment Bank. These files are then published to Payment 
Bank Host Application installed as a module at Payment Banks acting for the User. Messages 
are sorted and routed to the appropriate recipient. 

Risk parameters are used by the Payment Bank Host Application in the Filter Process 
Module of the present invention. The Filter Process Module is designed to mteroperate with an 

Page 19 of 59 



existing liquidity/payments manager to filter payments flowing between tiie payment queue 
maintained on the bank's existing internal systems and the external domestic payment system(s) 
to ensure that all payments made on behalf of a User comply with the User's risk parameters. 
The fundamental mechanism is tiie comparison of the payment amount in a payment instruction 
against an available balance calculated for the recipient Counterparty. Where the payment 
amount is within the available balance, the payment instruction is allowed to proceed. Where the 
payment amount is greater than the available balance, the payment instruction is rejected back to 
the payment queue for later reassessment. As payments from a Counterparty are received, the 
available balance rises; as payments are made Uie available balance falls. The Filter Process 
Module acts as the shuttle on a loom, ensuring payments flow back and forth between an account 
holder and any Counterparty in balanced measure. Users and Third Parties will be able to 
instruct overrides to the Filter Process Module for specifically identified payment transactions or 
Counterparties. The Payment Bank may override the risk parameters with a manual mstruction, 
in its discretion or at the request of a User. This feature may facilitate liquidity in a payment 
system, particularly one that is illiquid or highly concentrated, where failure by one bank in the 
system to make a payment impedes tiie ability of another bank in the system to make a 
contingent payment (i.e., a bottleneck). 

The Payment Bank Host Application enables the Payment Bank to monitor the flows of 
payments to and from User accounts in respect of individual Counterparties, allowing them to 
detect an imbalance which impedes further payments in accordance with User parameters. The 
GPM System enables the Payment Bank to notify a User in real-time should a sustained 
imbalance in payments received from a Counterparty result in a failure to make payments to the 
Counterparty. Such an event may indicate liquidity or payment difficulties at the Counterparty, 
and would normally be the subject of inquiry by the User, and perhaps action to suspend further 
payments to the Counterparty in that and other currencies, and to raise any consequent liquidity 
shortfall which might impact systemic payment flows. 

The Filter Process Module of the present invention will have the important capability of 
automatically responding to a User or Third Party insti^ction to suspend all payments to a 
particular Counterparty, stopping all fiirther payments as they are submitted for checking during 
payments processmg. Alternatively, the Payment Bank may manually instiruct the Filter Process 
Module via the Payment Bank Host Application to stop all further payments to a particular 
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Counterparty, where it deems such action appropriate (e.g., where it has been notified of an 
insolvency or operations failure). This mechanism provides a very significant improvement on 
the ability to intervene to stop payments m the event of a known insolvency or other condition of 
similar concem. 

The GPM System facilitates broad range of communications between participants in 
connection with payments management. Some inquiries will be handled by the system on an 
automated basis. For example, Third Parties (via Users) and Users may request detailed or 
summary information about payment performance for Counterparties or currencies. Thhd Party 
and User requests will be routed via the GPM Network to the Payment Bank(s) acting on their 
behalf to the Payment Bank Host AppUcation. The Payment Bank Host Application has the 
capacity to automatically fulfill inquiry requirements according to data on the day* s activities, 
and will then send the inquiry response back through the GPM Network to the initiating User or 
Third Party. 

Real-time messaging will be available between all GPM System participants. A User 
who is alerted by a Payment Bank of a sustained payment failure may then make on-line inquiry 
to the Counterparty, where the Counterparty is also a User. The Counterparty can then make 
inquiry to his own Payment Bank to request clarification or resolution of the payments problem 
where it is not under his direct control. 

Reports are available on a periodic or on-demand basis for all GPM Network participants. 
All Third Party, User and Payment Bank Host Applications are capable of generating flexible, 
parameterized reports, according to the reqmrements of the request. Reports can contain data 
about Counterparties, currencies, payment types, failed payments and metrics of payment risk 
reduction calculated by the GPM Core System. The GPM Core System can also calculate 
performance metrics such as the efficiency of payments and liquidity management, and other 
relevant statistics. 

Other advantages of the present invention will become apparent hereinafter. 

Brief Description Of the Drawings 
For a more complete understanding of the Objects of the Invention, the following 
Detailed Description of the Illustrative Embodiments should be read in conjunction with the 
accompanying Ehrawmgs, wherein: 
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Fig. 1 is a tabular schematic of tiie prior art three-day process for gross (transaction by 
transaction) foreign exchange settlements; 

Fig. 2 is a table listing the difiFerent types of risks arising in payments systems; 

Fig. 3 is a schematic diagram of the network for commmiications in the GPM System of 
the present invention, shown realized as a plurality of Third Party and User client workstations, 
applications interfaces and Web applications in operable communications with one another 
through a Web-enabled architecture, embracing both existmg mtemet protocol networks widely 
in use in the financial markets and interlinked to a virtual private network for communications 
between the GPM Core System and the Payment Bank Host Application installed withm 
Payment Bank systems; 

Fig. 4 is a schematic diagram of the GPM Core System of the present invention, shown 
realized as a plurality of client-server workstations, the whole being connected by a plurality of 
mtemet protocol networks to the GPM Core System and by a virtual private network (VPN) to 
Payment Banks; 

Fig. 5 is a schematic of the digital certificate issuance and usage process; 

Fig. 6 is a tabular schematic of the three-day process for foreign exchange settlements 
incorporating the Granular Payment Management processes; 

Fig. 7 is a schematic diagram of the flow of risk parameters, suspend instructions and 
messaging through the GPM System of the present invention; 

Fig. 8 is a schematic representation of the controlled and sequenced flows of payments 
between two Users via their Payment Banks; 

Fig. 9A1 is a schematic representation of Risk Parameter Instruction Process in the GPM 
System of the present invention; 

Fig. 9A2 is a tabular schematic of a message format capable of instructing payment risk 
parameters to a Payment Bank according to an illustrative embodiment of the present invention; 

Fig. 9B is a listmg of the Risk Parameters required for use in the Filter Process of the 
Payment Bank Host Application of the present invention; 

Fig. 9C is a schematic representation of the modular nature of the Filter Process m the 
Payment Bank Host Application, acting as an adjunct to existing liquidity/payments management 
software operatmg within banks dkectiy interfacing to domestic payment systems; 
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Fig. 9D1 is a step-by-step textual description of the Filter Process of Fig. 9C according to 
an illustrative embodiment of the present invention; 

Fig. 9D2 is a schematic representation of the Filter Process of Fig. 9C according to an 
illustrative embodiment of the present invention; 

Fig. 9E1 is a step-by-step textual description of the method for calculating the Available 
Balance parameter required for the Filter Process of Fig. 9C according to an illustrative 
embodiment of the present invention; 

Fig. 9E2 is a schematic representation of the method for calculating the Available 
Balance parameter required for the Filter Process of Fig. 9C according to an illustrative 
embodiment of the present invention; 

Fig. 9F1 is a schematic representation of the instruction and confirmation process 
involved in suspending payment according to the present invention; 

Fig. 9F2 is a tabular schematic of a message format capable of instructing suspension of 
payments in respect of a selected Counterparty according to an illustrative embodiment of the 
present invention; 

Fig, 9F3 is a step-by-step textual description of the method for suspending payments, as 
originated in the Third Party or User Host Application, processed through the GPM Core 
System, and implemented via the Filter Process in the Payment Bank Host Application according 
to an illustrative embodiment of the present invention; and 

Fig. 10 is a graphical representation demonstratmg the advantages of the present 
invention for reducing and controlling levels of payment risk as between two counterparties both 
using the GPM System of the present invention. 

Description of Embodiments of the Present Invention 

Referring to the figures of Fig. 3 through 10 , embodmaents of the present invention will 
be described in detail below, wherein like elements and structures will be indicated using like 
reference numerals. 

In general, the Granular Payments Management (GPM) system of the present invention 
may be realized in a variety of ways depending on the enabling technology available at the time 

Page 23 of 59 



of realization and particular application requirements at hand. In particular, it is expressly 
recognised that standards for data interchange are evolving and that industry standard data 
formats and messaging protocols may be subject to amendment. 

As shown in Fig. 3, the GPM System of the illustrative embodiment is shown comprising 
a Web-based network of client-server workstations on which Web-server and Web-linked 
interface applications are supported, and Third Party, User and Payment Bank Host Applications, 
and spatially distributed about the planet Earth in order to provide real-time service to the diverse 
Third Parties, Users and Payment Banks tlliat the system is designed to serve. It is understood, 
however, that the system can be realized in other ways. 

As shown in Fig. 3, the GPM System involves a network of connected Third Party Host 
Applications, User Host Applications, Payment Bank Host Applications and the GPM Core 
System running on the Web-based client-server information network. The schematic for the 
illustrative embodiment demonstrates the flexibility of the network for interconnecting those 
involved in payment flows. Third Party (4) and User (1) access mechanisms include: a plurality 
of proprietary network access workstations, personal computers, internally networked clients 
accessing servers, application-to-application integration with back office transaction processing 
systems, and other arrangements promoting ease of access and flexible use. 

The Third Party host application (4) will connect to a User host application (1) via 
network arrangements agreed between them and using internet protocol communications 
networks, whether private, commercial or the Internet. The Third Party Host AppUcation will be 
capable of automated interoperability with the User Host Application to set risk management 
parameters for processing of payments on behalf of Third Parties where the User acts as 
correspondent, to generate suspend instructions when necessary, to generate overrides as 
necessary, and to define requirements for messaging, inquiries or reports via the GPM Network. 

Users will be interconnected to the GPM Virtual Private Network (GPMA^PN) (6.1) via 
routers (6.3) and a variety of internet protocol networks (6.2), likely to include the private and 
commercial networks most widely used in the financial sector, but potentially includmg the 
Intemet. 

The VPN interconnects via a router (6.3) to the GPM Core System (2). It is expressly 
recognised that the VPN functionality may be alternatively realised by advances in network 
security and authentication processes. 

Page 24 of 59 



In the illust-ative embodiment, liie GPM Core System processes the data received from 
the plurality of Users into data to be published to the plurality of Payment Banks. The GPM 
Core System communicates via flie VPN to the Payment Bank Host Application (3) installed as a 
modular component within the payment systems of Payment Banks. The Payment Banks then 
further interface to the domestic payment system(s) for each currency (5) using the established 
present interfaces and networks. 

An important feature of the present invention as depicted in the illustrative embodiment 
is the capability for many-to-many publishmg of payments data from and to diverse data formats 
as used wilhin the heterogeneous plurality of Third Parties, Users and Payment Banks. The use 
of open software applications capable of integration with any computing platform, and 
extensible Mark-up Language (XML) as the data format protocol in the Third Party Host 
Application, User Host Application and Payment Bank Host Application, will promote the 
interoperability of the GPM System with legacy systems and appUcations within Third Parties, 
Users and Payment Banks. 

XML has several critical advantages. Fkst, XML is both human-readable using browsers 
and XSL stylesheets, and machine-readable for application-to-application automated processmg. 
Second, it is an open standard capable of ready translation via data mapping into other existing 
data standards (mcludmg S.W.I.F.T. and other EDI standards) using commercially available 
translation methodologies. This will promote interoperability with existing risk management, 
payment and other computerised and automated systems witiiin Third Parties, Users and 
Payment Banks, Third, commercially available software exists to map or translate data from and 
to XML for other data formats. This means that Users can store data in their internal systems in 
pre-existing formats, and still use the data to populate their GPM inputs without replication or 
risk of inconsistency. Finally, XML is very flexible and extensible, allowing the creation of new 
data formats and data fields without impacting pre-existing applications and systems. This 
capacity can be used, for example, to expand the range and scope of the GPM System without 
impacting the interfaces with payments applications. 

Human interaction with the GPM System will use browser mterfaces. The use of a 
browser interface has significant advantages: it will be familiar to vutually all users of 
technology; it can be structured with customised "drop-down" lists for populating data fields for 
easy "pick and click" selection of counterparties, TMrd Parties, Users, Payment Banks, 
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currencies and other categories of data; and it can accommodate free text messaging when 
appropriate. In particular, most recent instances of browsers are capable of supporting 
extensible Mark-up Language (XML), the data format protocol selected for the illustrative 
embodiment of the present invention, through the application of XSL stylesheets to the data. A 
further advantage of browser interface is that the User Host Application and Payment Bank Host 
Application can be installed with a corporate information technology system, capable of remote 
access from a plurality of geographically dispersed sites. This will facilitate "passing the book" 
of payments risk management between geographically dispersed branches and offices, where a 
Payment Bank or User wishes to actively manage and monitor payments activities worldwide. 

As shown in Fig. 4, the GPM System of tihie illustrative embodiment comprises a plurality 
of access devices and applications for Users (1), providing and receiving data to and from the 
GPM Core System by way of a plurality of internet protocol networks (6.2), which are 
interconnected by way of routers (6.3) to the VPN (6.1) serving the GPM System. The VPN is 
then connected via router to the GPM Core System (2). 

The GPM Core System in the illustrative embodiment comprises: a plurality of personal 
computers or servers (e.g., IBM or sunilar) providing an Operations Workstation (2.1), Database 
Server (2.2), Authentication Server (2.3), Process Server (2.4) and Web Server (2.5), each 
interconnected to a Local Area Network (LAN) (2.6). A remote hot Backup System in the 
illustrative embodiment comprises a Backup Operations Workstation (2.7), Backup/Mirrored 
Database Server (2.8), Backup Process & Authentication Server (2.9) and Backup Web Server 
(2.10), each interconnected to a LAN (2.1 1). The GPM Core System and Backup System are via 
their respective LANs by bridges (2.12), in a conventional manner. The GPM Core System 
connects by way of the VPN (6.1) to the Payment Bank host applications (3) installed in the 
Payment Banks in the GPM System. 

The User Host Application is optimally installed on a server within the User's own 
internal back-office systems and accessed from a workstation, personal computer or network 
access device. The User Host Application will usually be located at the User site principally 
associated with clearing and setdement of payments transactions, although it is understood that 
each instance of the User Host Application will promote flexibility in User access, and may be 
networked via internal User networks using conventional communication networking technology 
well known in the art. 



Page 26 of 59 



In the illustrative embodiment, each instance of the User Host Application at the User site 
supports a browser interface. The particular character of the browser interface may vary from 
embodiment to embodiment of the invention to flexibly adapt to the User's requirements, 
complexity, various instances of the User Host Application, and means of GPM Network access. 
However, it is preferred that each such browser interface supports an array of display screens 
using extensible Stylesheet Language (XSL) stylesheets which enables Hyper-Text Markup 
Language (HTML) representation of XML data and document type definitions (DTDs), and 
facilitates easy entry of information by the User during the day, as well as displaying various 
types of reports and notifications produced by the GPM Core System. (It is noted that the 
invention could be realized at the User site to support a graphical user interface (GUI) using a 
GUI generator. In such a realization, the installation at the customer site would operate as a 
client on the server on which the User Host Application is installed.) 

The computers used to realize each instance of the User Host Application can run 
vutually any type of operating system, such as the Microsoft Windows NT operating system, 
Microsoft Wuidows 2000 operating system, earlier versions of the Microsoft Windows operatmg 
system, Unix operatmg system, or the Macintosh operating system, or operating systems now 
emerging to make better use of emerging technologies. 

Each User Host Application instance cooperates with central server processes operating 
on the GPM Core System Servers at the central site by way of the data-packet network 
communication protocol supported over the VPN, and interconnected intemet protocol networks. 
The User Host Application and GPM Core System will exchange data using an application-to- 
application interface. 

In the illustrative embodiment, each mstance of the Payment Bank Host Application 
installed on a server at the Payment Bank site supports a Filter Process Module which will 
interoperate in a modular manner with the pre-existing Liquidity/Payments Manager software 
already installed in the Payment Bank's legacy system for payments processing. The particular 
character of the interface may vary fi-om embodiment to embodiment of the Filter Process 
Module to flexibly adapt to the Payment Bank's existing systems and the interface requirements 
of the domestic payment system and/or miultiple payment channels. 

Payment Banks will additionally have a browser interface to the Payment Bank Host 
Application for monitoring payment flows. Third Party and User risk parameters, inquiries. 
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messaging and reports. This browser interface will also be used to instruct manual override to 
enable particular payments or to suspend payments to a particular Counterparty, where this is 
deemed appropriate in the Payment Bank's discretion. The computers used to realize each 
instance of the Payment Bank Host Application can run virtually any type of operating system, 
as above for the User Host Application. The browser interface and data structure for the 
invention will support multiple languages and the global character set used commonly 
worldwide. (It is noted that the application-to-application interface could be realized as an 
application client on the client-server architecture of the GPM Core System, and fliat the 
Payment Bank interface could be realized similarly with a GUI.) 

In the illustrative embodiment, the processes of the present invention in the GPM Core 
System are realized as client-server based processes, wherein the Process Server supports the 
server portion of the process, while a GPM Operations Workstation supports the client portion 
thereof In order to reaUze such client-server processes upon the GPM Core System, a data- 
packet network communication protocol is employed. The GPM Core System uses a suitable 
network communications product commercially available from a vendor of information bus 
technology (e.g., Tibco, IBM, etc.). The benefits of using a bus architecture include flexibility, 
extensibility, easier maintenance, improved security and the reinforcement of design goals such 
as modularity, abstraction and encapsulation. The network communication may altematively be 
supported by messaging middleware (e.g., MQ Series). 

All information items pertaining to Third Parties, Users, Payment Banks and parameters 
for processing in the GPM System, inquiries, messages and reporting, and the like are 
maintained within a database maintained within the GPM Database Server (7). In the preferred 
embodiment, this database is realized as a relational database using commercially available 
database management computer software (e.g., Oracle, IBM DB2), 

In the illustrative embodiment, the virtual private network (VPN) (4) provides 
appropriately high levels of security and integrity for all communications across the GPM 
network using commercially available teetmology for encryption, firewalls, anti-hacking 
measures, and assured message and data delivery. 

As shown in Fig. 5, tiie GPM System of the illustrative embodiment will use a system of 
digital certification to ensure the security of network access against use or infiltration by 
unauthorised persons. A digital certification process, commercially available from several 
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digital certification authorities, will be used to issue digital certificates to all remote host 
applications and to ensure their use whenever any remote host appUcation accesses the GPM 
Core System at the initiation of a session. Participant authentication may alternatively be 
supported by various security technologies commercially available or under development. 

In addition, all transmissions via the GPM Network will be digitally encrypted using 
security technology suitable for high security banking applications. 

As shown in Fig. 6, the GPM System of the present invention will greatly alter the risk 
profile attaching to foreign exchange settlements, but with relatively minor impact on 
conventional processes used by participants and thek branches or correspondent banks 
(collectively "Payment Banks" for GPM). 

Fig. 6 describes the chaiges firom the perspective of a foreign exchange market 
participant, but a similar impact would be observed for any financial market participant involved 
in regular flows of large value payments. On the Trade Date, the dealmg, confirmation, 
matching and payment instructions contmue as before. But following the generation of payment 
instructions, the GPM User Host AppUcation will allow a User to construct a profile of their 
payment risk in each currency vis-a-vis each Counteaparty. Using this software and thek own 
discretion regarding the tolerance of thek institution for credit risk on each Counterparty, the 
User can generate a file of payment risk parameters to control the payment risk by Counterparty, 
currency and payment type. The parameters for each Counterparty will be set independentiy for 
each currency for which GPM operates. The limits can be set dififerentiy for each currency, (e.g., 
$100M in US dollar, as a very liquid currency, but only $10M in Malaysian Ringgit, as a 
relatively illiquid currency). The parameters can also be set according to payment type in 
accordance with the definition of payment message types by S.W.I.F.T. and the various 
alternative domestic payment systems or book tiansfer (payment chminels). 

On the Setdement Date, the Payment Bank constructs the payment queue of payment 
messages for that date. The GPM Filter Process Module is a modular software component actmg 
in a complementary manner to existing liquidity and payment queue management software 
interfacmg to the domestic payment system. As before, the Liquidity/Payment Manager assesses 
whether sufficient liquidity exists in the clearing account witii the domestic payment system to 
enable an outgomg payment. If the payment passes the Liquidity/Payment Manager, tiien the 
payment is additionally submitted to tiie GPM Filter Process Module. This module assesses the 
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payment message against the parameters set by a Third Party and/or User for the 
Counterparty(ies) to see whether the parameters will be violated by the outgoing payment The 
Filter Process will serially assess compliance with risk parameters for each Counterparty detailed 
on a payment transaction as eitiher payment beneficiary or payment intermediary. If no, then the 
payment is returned for processing to the interface with the domestic payment system as usual. 
If yes, then the payment is returned to the back of the payment queue for fiarther assessment next 
time it comes up in the queue. 

The GPM Filter Process Module will also assess whether a payment transaction, 
counterparty or intermediary is the subject of an override instruction. In which case, the 
payment transaction will be allowed to proceed to the domestic payment system regardless of the 
risk parameters. Payment Banks will generate S.W.I.F.T. MT900 and MT910 messages as 
before, where available. These messages and/or the data underlying their generation will be used 
to populate the metrics controlling the assessment of payments against the Available Balance 
calculated in the Filter Process Module. In particular, the Payor designation. Payee designation 
and tiie amounts of debits and credits will be extracted from the messages as data fields and used 
to update the Available Balance metric for the relevant counterparty and User/Third Party. 

The Payment Bank Host Application will retam a cache of the identifiers (for example, 
Transaction Reference Numbers for S.W.I.F.T. payment transactions) of payment transactions 
rejected by the Filter Process Module. This cache will be available for inquiry or reporting to 
enable the Payment Bank or Users or Third Parties to assess the impact of the Filter Process 
Module on their outgomg payments fraffic. 

The Payment Bank Host Application will be capable of issuing notifications as 
exceptions conditions arise. For example, where all payments to any Counterparty are rejected 
for a half-hour period (or other appropriate timespan), a notification may be issued to both the 
Payment Bank and the Third Party and/or User to apprise them of the sustained failure. On 
receiving this alert via the GPM network, the Third Party and/or User can make appropriate 
inquiries immediately. Where no substantial problem exists with a counterparty, a Third Party 
and/or User may instruct an override to Filter Process Module to enable payments to proceed on 
the basis of identified payment transactions, intermediaries or counterparties. 

If the Third Party and/or User has cause for real concern, however, he can suspend 
fiirther payments the counterparty or intermediary via the GPM Network in one, some or all 
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currencies. A mechanism for suspension of payments will result in the Filter Process Module 
rejecting any furdier payments for the counterparty, and may be effected for all currencies for 
which the participant uses the GPM System in one simple and efficient instruction. The early 
detection of a counterparty payment failure will also reduce the systemic impact of defaults by 
enabling a participant of the GPM System to calculate exactly his payment exposure to a 
counterparty, and to fund more reliably any shortfall (necessarily limited to the Clean Payment 
Limit parameter) in liquidity which might affect his own ability to make contingent payments in 
affected currencies. 

In some circumstances, a Thnd Party or User may wish to override the risk parameters 
instructed to the Filter Process Module at their Payment Bank for particular, identifiable payment 
transactions or Counterparties, Where an override instruction has been received, the Filter 
Process Module will permit a payment transaction to proceed regardless of whether it is within 
the available balance maintained for the relevant Counterparty. 

An inquiry to determine the Available Balance for the Counterparty at all Payment Banks 
will give the participant a precise measure of any payment exposure he has vis-a-vis the 
Counterparty. Because the Available Balance is updated in real-tune as payments are made, it 
provides very precise information on the Counterparty exposure and liquidity impact of a default. 

On a day-to-day basis the User can monitor his credit exposure across all currencies in 
respect of a particular Counterparty both periodically and on-demand in a much more efficient 
and reliable manner. The GPM System and User Host Application will enable flexible 
aggregation of payment flows to provide better information to support risk management and 
tradmg decisions vis-a-vis counterparties. When combined with the limits on payment risk 
operating hi the GPM System, the effect shoxild be to increase the global capacity for tradmg 
volumes by reducing the present credit constraints which arise due to gross payment exposures. 

There may be occasional situations in which a Payment Bank might wish to override the 
automated risk parameters of the Payment Bank Host Application to permit a payment to 
proceed, despite its non-compliance with risk parameters set by the User. In this event, an 
override facility is provided whereby the Payment Bank can permit individual payments, or 
payments to particular Counterparties, to proceed for payment despite the breach of risk 
parameters. 
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On the Reconciliation Date, the Users will use tiie MT950s generated as usual by 
Payment Banks for reconciliation in their existing processes, with no change to conventional 
practices. They can follow up on failed settiements of individual transactions accordingly but 
tiie advantage of learning of the amounts of payments not received on the day previous should 
eliminate much of the stress and uncertainty attendant on the process using prior art systems and 
techniques. 

As shown in Fig. 7, tiie GPM System is backward compatible witii existing messaging, 
payments and risk management processes withm market participants and payment banks. The 
GPM System supplements tiie current infrastiiicture by providing a logical flow of information 
between account holders and payment banks to improve the functionality of payments control 
and also communications between banks and account holders. In the illustrated schematic, tiie 
User receives confirmation of market transactions (A) from the S.W.I.F.T. network. The 
transaction is matched (B), and the payment instructions are generated (C) and sent (D) via the 
S.W.I.F.T. network to tiie Payment Bank (E). At tiie Payment Bank, tiie payment instiiictions 
are lodged in a forward payment instructions cache (F) until tiie payment date. The User tiien 
forwards the information about payments exposures to his risk management operations. The risk 
management operations will determine appropriate levels of risk exposure to the counterparty 
according to tolerance for counterparty credit risk, currency liquidity risk and other measures 
(G). The resulting risk parameters are entered (H) in the module for generating risk parameters 
and suspend instructions in the User Host Application (1 . 1). The User Host Application 
communicates tiiese risk parameters to tiie GPM Core System (I), which applies rules-based 
processing (J) and data storage, and forwards tiie risk parameters (K) to tiie Filter Process 
Module in tiie Payment Bank Host Application via application-to-application data interchange. 

On tiie payment date, a queue of all pending payments messages is constructed from the 
stored payment instiiictions(L). As payments operations commence, each payment message is 
forwarded to the payments or liquidity management software contiroUing payments sent to tiie 
domestic payment system (M). If tiie payment fails tiie parameters in tiiis process, it is returned 
to tiie queue (N). If it passes, tiien it is forwarded to tiie Filter Process Module cooperating witii 
tiie existing payments or liquidity management software (O). The Filter Process Module 
assesses tiie payment against tiie risk parameters for tiie Counterparty(ies) (P). If it fails, the 
payment message is retiimed to the payments queue and details of tiie tiansaction are cached for 
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reporting and reference (Q). If it passes, details of the transaction are cached and the payment 
message is forwarded (R) to the domestic payment ^stem for payment (S). 

Data regarding incoming payments are captured to populate the Available Balance 
metrics essential to the Filter Process Module (T). 

Notifications, messages, inquiries and reports can flow between the User and the 
Payment Bank via the GPM System in an automated or on-demand basis. In the illustration, the 
Payment Bank may generate a notification (U) which is sent (V) via the Core System messaging 
facility (W) and relayed (X) to the User Host Application for notification (Y) of the User. All 
message traffic is stored for audit purposes (Z). 

As shown in Fig. 8, the GPM System of the present invention enables payments to be 
randomly sequenced as between two financial market participants so that no great imbalance in 
credit exposure occurs between them. Payments are released by the Filter Process Module up to 
the Clean Payment Limit, as determined by the Third Party or User. Following that, further 
payments to the same counterparty will be filtered and returned to the payments queue, unless 
permitted by override. Only when receipts of expected payments fi-om the Counterparty are 
credited to the User's account (designating either the User or a Third Party as recipient) will 
further payments be released. In this manner, the Filter Process Module ensures the regularity 
and moderation of payment flows between two parties. 

Only one party needs to be a User or Third Party for the GPM System to prove effective. 
The ability to control risk without the express agreement or cooperation of a counterparty is a 
significant innovation. 

As shown in Fig. 9A1, the Third Parties and Users accessing the GPM System will 
generate and send instructions (A and B) to their Payment Banks (branches and banks making 
payments on their behalf mto domestic payment systems) to control the payments against risk 
parameters. Separate instructions will be generated for each Counterparty in each currency. 
Currencies will be identified by ISO codes. These risk parameters are designed to control the 
level of payment risk and liquidity risk arising in comiection with a Counterparty. The Third 
Party Host Application (4) will be capable of generating risk parameters, but will not have direct 
access to the GPM System. The Third Party must therefore forward its risk parameters to a User 
acting on his behalf (A). The User Host Application (1) can generate risk parameters on behalf 
of the User and Thnd Parties, and send these, as well as relaying any Third Party risk parameters. 
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to the GPM Core System (B). The GPM Core System (2) will analyse and sort received data 
files using rules-based processing. Data will be stored, and also forwarded to designated 
recipients. Risk parameters will be forwarded to the Payment Banks (C) designated as making 
payments on behalf of Users and Third Parties. The Payment Bank Host Application (3) will 
store received risk parameters and apply them during the Filter Process (D). Only payment 
instructions passing the parameters in the Filter Process will be forwarded to the Domestic 
Payment System (5) for payment (E). 

As shown in Fig. 9A2, is an example of the data fields the risk parameter instruction 
generated by the Third Party or User Host Application might contain, using industry standard 
formats and showing a variety of data relevant to the routing and application of the risk 
parameters. The data format fields follow content standards defined by S.W.I.F.T. for payment 
messages, and so will be backward compatible with existing payment processing systems and 
industry conventions. Although the data is presented here in the format of an mdustry standard 
message, the data in the Third Party or User Host Application will be generated using a flexible 
browser interface, allowing easy and transparent selection of counterparties, intermediaries, 
currencies, payment types and may use different data format elements or standards. It will be 
captured in the format of an XML document type definition (DTD) suitable for the structure of 
data, and in particular the need for flexibility in the characterisation of counterparties. The 
representation here indicates that there can be multiple counterparties or intermediaries 
designated as subject to a single risk parameter. This will be particularly useful for aggregating 
affiliated branches or corporate entities which are likely to be mutually implicated in a default or 
insolvency. In this manner, a User or Third Party can control risk in a manner tailored to his 
perception of correlation among affiliated or similar trading entities. The representation also 
permits multiple categories of Payment Type, recognizing that Users or Third Parties may wish 
to be selective in applying GPM processing to particular categories or sizes of payments or 
alternative payment channels. 

Fig. 9B provides examples of the Risk Parameters utilized by the Filter Process. Note 
that tiie Risk Parameters may be quite simple, including for each currency independently of the 
Counterparty (however designated or aggregated), the Clean Payment Limit, and designation of 
Payment Types. These three parameters are sufficient to enable the Filter Process to control the 
payment risk and liquidity risk arising in connection with the Counterparty for all payments of 
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the designated types. Note that these Risk Parameters are provided as examples. Other 
parameter may be used to generate a risk profile that accurately correlates risk of releasing 
payment to the payment beneficiary for a given payment. 

Fig. 9C illustrated as exemplary embodiment of the Filter Process Module of the 
Payment Bank Host Application. The Filter Process Module is intended to co-operate and be 
backward compatible with the existing liquidity and/or payments management software 
controlling the outflow of payments instructions to the domestic payment system. Such 
software may either be developed bespoke by a bank or provided by a software vendor. 
Liquidity/Payment Managers are software typically designed to evaluate individual payments 
messages against (a) the available balance overall for the bank in the domestic payment clearing 
account (generally an account held at the central bank for a real-time gross payment system), and 
(b) the available balance in the account of the account holder referenced in the payment 
instruction (the account to which a debit will be made for the payment). If a payment instruction 
fails either check, it is rejected back to the payments queue for re-evaluation later. Where a 
payment instruction clears these two parameterized evaluations, and any other filters a bank or 
domestic payment system or local law or custom may impose, it is forwarded for payment 
through the gateway to tiie domestic payment system. 

The Filter Process Module in the Payment Bank Host Application will be a modular 
extension of the parameterized evaluation already operating in the Liquidity/Payments Manager. 
Using an application-to-application interface which translates the data formats of the 
liquidity/payments manager to the data formats of the Filter Process Module, and back again, the 
two application modules can interoperate without retooling of the existing application. Payments 
clearing the assessments of the legacy Liquidity/Payments Manager will be forwarded to the 
Filter Process Module for assessment. If they fail such assessment, they are returned to the 
queue as before. If they pass, they are forwarded to the gateway to the domestic payment system 
as before. This modular integration with existing systems offers backward compatibility, 
providing lower integration costs and widespread adaptability of the GPM process. 

As shown in Fig. 9D1 and 9D2, the Filter Process Module of Fig. 9C operates a logical 
algorithm for assessment of payments instructions. The process assumes that a payment 
instruction has been transmitted from the Liquidity/Payments Manager application within the 
Payment Bank's systems to the Filter Process Module for evaluation. As shown in Fig. 9D1, 
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Step A of the Filter Process identifies the Payor on the payment instruction message. This will 
be possible using industry standard fields (e.g., Bank Identifier Code or sunilar domestic field 
tag). 

Step B of the Filter Process involves assessing whether the Payor is a User or Third Party 
using the GPM System. If NO, then the payment instruction is passed back to the 
liquidity/payment manager for transmission to the domestic payment system interface without 
finther evaluation. If YES, then the Filter Process Module proceeds to Step C, identifying the 
payment beneficiary and intermediaries on the payment message. Intermediaries will be financial 
institutions handling the payment in the chain of accounts leading to the beneficiary, as identified 
on payment messages using standard industry formats. 

Step D of the Filter Process involves assessing whether the payment beneficiary and any 
intermediaries are designated Counterparties of the User or Third Party. The record of 
Counterparties is maintained for each User and Third Party within the Payment Bank Host 
Application. If the neither the payment beneficiary nor any intermediary is a Counterparty for 
granular payments management, the payment instruction is passed back to the Uquidity/payments 
manager for processing to the domestic payment system. If the payment beneficiary or any 
intermediary is a Counterparty as defined in the risk parameters, then the Filter Process Module 
goes to Step El and E2 for each Counterparty to determine whether an override instruction has 
been received for a particular transaction or Counterparty (step El) and whether the counterparty 
or intermediary is suspended fi-om further payments (step E2). 

In Step El, the Filter Process assesses whether an override instruction has been received 
for a particular transaction or Counterparty. Preferably, the Filter Process looks to the 
Transaction Reference Number (Field 20 in S.W.LF.T. format messages) of the payment 
instruction under analysis and assesses whether an override instruction for that Transaction 
Reference Number is stored in a database of received override instructions. If not, it looks to the 
Coimterparty identifiers of the payment instruction and assesses whether an override for these 
institutions is stored in a database of received override instructions. Where an override has been 
instructed, the Filter Process enables payment through the domestic payment system and updates 
tiie Available Balance by subtracting die payment amount. Preferably, an override instruction 
for one Counterparty on a payment message referencing more than one Counterparty will pass 
tiie Filter for the override Counterparty, but the Filter will still operate to check risk parameters 
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in respect of all other Counterparties referenced as payment beneficiaiy or intermediaries. If an 
override has not been instructed tiie operation continues to step E2. 

In step E2, the Filter Process assesses whether any Counterparty has been suspended. If 
so, all payments messages referencing the suspended Counterparty will be rejected back to the 
payments queue until such time as the suspension may be lifted, otherwise operation continues to 
step F. 

At Step F, the Filter Process Module identifies the payment type of the payment message 
under analysis and proceeds to step G to determine whether the identified payment type has been 
designated (in received risk parameter instructions) for processing by the Filter Process Module 
The default operation will be to subject all payment types to the Filter Process unless only 
specific payment types have been designated (in received risk parameter instructions) for 
processing by the Filter Process Module. Payment Type eligibility could be parameterised to 
assess a number of alternative payment characteristics, including but not limited to the minimum 
value of payments for filtering (e.g., $250,000 or more), whether a payment is intermediated 
(e.g., filtering on whetiier the Counterparty is a beneficiary or intermediary), and other factors. If 
the payment is of a type which makes it eligible for filtering, the processing continues to step H, 
otherwise the payment message is passed back to tiie liquidity/payment software for further 
processing to the payment system. 

This step can also be used to differentiate payment channels where there are more than 
one domestic payment systems. For example, tiie United States has two large value payments 
systems: Fedwu-e operated by tiie Federal Reserve System, and tiie Clearing House Interbank 
Payment System (CHIPS), operated cooperatively by tiie New York Clearing House Association. 
The payment type identifier m tiie risk parameters can be structiired to reference tiie various 
payment, so that, for example, payment instructions for Fedwire would be subjected to the Filter 
Process but payment instinctions for CHIPS would not. (Where separate liquidity/payments 
managers operate for separate payment channels, the Filter Process Module could be mstalled m 
multiple instances within the Payment Bank, achieving tiie same objective. 

In step H, tiie Filter Process identifies tiie payment amount from tiie payment mstmction 
(e.g., Field 32A on a S.W.LF.T. message type). 

Step I of tiie Filter Process Module involves calculating the Available Balance for the 
counterparty. This hivolves a process explained fully below. 
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Step J of the Filter Process Module involves comparing the Available Balance against the 
payment amount Where the Available Balance exceeds the payment amount, the payment 
instruction is passed back to the liquidity/payments manager for further processing. Where the 
payment amount exceeds the Available Balance, tiie instruction is rejected back to the payments 
queue, and the liquidity/payments manager notified accordingly. 

Finally, at Step K of the Filter Process, the Available Balance is reduced by the amount 
of any payment and stored. 

Whether a payment message is passed or failed, the Filter Process Module records the 
details of the transaction for audit and data cache purposes. This information may be used to 
populate reports about successful and failed payments. 

As shown in Fig. 9E1 and Fig. 9E2, the Available Balance used in the Filter Process 
Module of Figs. 9D1 and 9D2 is preferably calculated using a logical algorithm with seven steps. 
Step I.l is to identify the User or Third Party (as done in Step A of the Filter Process). Step 1.2 is 
to identify the Counterparty (as done in Step B of the Filter Process). Step 1.3 is to identify the 
stored Available Balance. This amount will be either (a) the Clean Payment Limit at the 
beginning of payments processmg for Hie day, (b) the stored Available Balance as revised during 
Step K of the Filter Process, or (c) the stored Available Balance as revised by receipt of amended 
Risk Parameters specifying a change to the Clean Payment Limit. 

At Step 1.4, the process for calculating the Available Balance sends a timestamped 
inquiry to the payments/liquidity manager or other appropriate ^plication to determine whether 
incoming payments have been received designating the User or Thu-d Party under consideration 
as a beneficiaiy since the last timestamped request. If so, the amounts of any such payments are 
totaled (Step 1.5) and added to the Available Balance (Step L6). The recalculated Available 
Balance is stored and forwarded (Step 1.7) to the Filter Process in fiilfiUment of Step I of that 
process. 

As shown in Fig. 9F1, the same process used for generating and sending risk parameters 
can also be used to generate and send instioictions to suspend all payments to a particular 
Counterparty or intermediary. The GPM System will enable a User (or Third Party via a User) 
to suspend all fiirther payments to a designated Counterparty or intermediary in one, several or 
all currencies with an mstantaneous instruction. The Third Party (4) or User Host Application 
(1) initiates the process of suspension. Using the browser mterface to the host application, the 
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User or Third Party selects the Counterparty (from a drop down list), selects the currencies for 
which suspension is sought (from a drop down list) and then clicks on a button generate a 
Suspend Instruction. The application will ask the User or Third Party to confirm the instruction 
according to its terms as a precaution appropriate to so serious an intervention in the payments 
process. Where the Suspend Instruction is confirmed, it is sent via the GPM Network to the 
GPM Core System (Step A on Fig. 9F1). 

The GPM Core System identifies Payment Banks for receipt of the Suspend Instruction 
acting for the User m the affected currencies. The Core System then routes the Suspend 
Instruction via the GPM Network to the Payment Bank Host Application (3) (Step B on Fig. 
9F1). The Payment Bank Host Application sets the trigger in the Filter Process to determine that 
the Counterparty has been suspended (Step C on Fig. 9F1). When a payment instruction for the 
Counterparty comes through the Filter Process, it will be rejected and returned to the payments 
queue (Step E on Fig. 9D1 and Fig. 9D2). As a result, no payments for that Counterp^ty as 
beneficiary or intermediary will be permitted until the trigger is reset to remove the suspension 
(in the event the Coimterparty is reinstated). 

Once the trigger in the Filter Process has been set to Suspended for a Counterparty, the 
Payment Bank Host Application generates an automated notification to confirm implementation 
of the Suspend Instruction (Step D on Fig. 9F1). The notification is passed through the GPM 
Core System back to the User (Step E) and Third Party, if any (Step F), where the confirmation 
of the Suspend Instruction is notified as m alert and stored. 

The process of the present invention described hereinabove represents a very important 
advance in the control of payments risk during a default crisis. In many countries, the legal 
system applyuig in bankruptcy allows for the unwinding of payments which are made after an 
insolvency petition is filed or, in some coimtries, all payments occurring on the date of an 
insolvency from midnight onwards. As a result, the unwinding process can result in great 
dislocation to payments systems, resulting in imquantifiable payments risk, liquidity risk and 
systemic risk. The earlier a party to a transaction can intervene to prevent further payments, the 
better. The GPM System presents a significant innovation in enabling a participant to suspend 
payments in all currencies for a counterparty from the moment he first leams of a default or 
hisolvency situation, while at the same time allowing the participmit to know exactly the extent 
of his payment risk and liquidity risk in each currency (the Clean Payment Limit). 
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The Suspend Instruction will remain a bar to all further payments in the Filter Process 
until processing is reinstated. Reinstatement is achieved by the simple mechanism of sending a 
new Risk Parameter Instruction referencing the suspended Counterparty. When received by the 
Filter Process, the suspension trigger is reset and the new risk parameters are implemented in 
Filter Process logic. 

As shown in Fig. 9F2, an exemplary Suspension Instruction message includes fields that 
identify the Third Party and/or User originating the Suspend Instruction, the Payment Bank 
addressed by the Suspend Instruction, the Counterparty suspended, and the nature of the 
instruction as a Suspend Instruction. 

As shown in Fig. 9F3, the steps alluded to in Fig. 9F1 can be detailed within the process 
for the Third Party or User Host Application, the GPM Core System and the Payment Bank Host 
Application, Together, the processes provide an effective and secure means of rapidly 
suspending payments to a Counterparty where there are reasonable grounds for fearing that the 
Counterparty is insolvent or otherwise incapable of performing his obligations. 

Method Of Using The GPM Svstem Of The Present Invention 
Having described the illustrative embodiment of the GPM System hereof, it is 
appropriate at this juncture to describe a preferred method of using the same. 

Opening an Account with GPM 

Each entity involved in the GPM System, whether User, Third Party, Payment Bank or 
Counterparty will have a Unique Identifier (UID). For Payment Banks and many Users, this will 
be then- BIC code. Other Users and Third Parties may have a unique industry standard identifier 
of another sort, which can be used by the GPM System. Otherwise, the GPM System will issue 
its own unique identifier in a format analogous to the BIC code. The unique identifier will 
enable the GPM System to track an entity's involvement in the system, regardless of the nature of 
its role ui any particular system action. 

Users 

Each User wiU have at least one account within the GPM System. Each account can 
support one or more User or Third Party identities, or a combination thereof Users may flexibly 
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identify themselves, affiliates or others as Users or Third Parties such that various hierarchies of 
corporate affiliates, branches, clients and other sub-groupings are separately accounted for within 
the GPM System. Users may reflect their organizational and administrative hierarchy by 
identifying Users or Third Parties as they choose, including providing client identifiers used in 
their internal systems, and may create various account hierarchies for aggregation or 
desegregation of risk management and reporting. 

In the illustrative embodiment, Users will seek to open an account on-line via a Website 
maintained on the World Wide Web or other Web(s) by the GPM System. If accepted on 
review, the GPM System will automatically issue account identifiers to Users as accounts are 
opened in the system. GPM operations personnel shall issue, modify and manage customer 
account creation, deletion and security features, including user logins, passwords, and 
authorisation verification procedures in connection with access privileges for each employee 
within a User. 

In addition, the GPM System will make use of global digital certification. Each User will 
require issuance of a digital certificate as part of the User acceptance process. Each session with 
the GPM System thereafter will begin with verification of the digital certificate details with the 
digital certification authority. 

The GPM System will identify each User or Third Party account separately, but many 
Users may wish to aggregate an account hierarchy to promote more efficient liquidity and/or risk 
management in connection with their payments activities. Users may elect to create one or more 
"synthetic" accounts representing an aggregation of User and/or Third Party accounts. By way 
of example, a foreign exchange dealer may wish to create individual Third Party accounts for 
each client for which the dealer acts in negotiation and settlement of foreign exchange 
transactions. However, in order to manage his liquidity and payments risk across the range of 
client accounts, he may elect to aggregate the accounts into a single master account. 

User details necessary for the management and billing will be stored on the GPM Data 
Server. These details will include, but are not limited to account name, company name, contact 
name, address, telephone number, facsimile number, e-mail address, accoimt number, billing 
information, and communication information. 

All User access will be protected through a User-based access/entitlement security 
mechanism including digital certification. Only properly authorised Users will have the ability 
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to instigate GPM System actions, including creating and modifying Third Party, User and 
counterparty details, entering or modifying Net Payment Limits, entering or modifying Risk 
Parameters, instructing Suspend Instructions for suspension of further pa3nments, and creating or 
altering report formats, or generate messaging, inquiries, and other system actions. 

On an ongoing basis, the GPM System maintains records of User access and usage of the 
GPM System, and Users will have access to these records by way of inquiry and report facilities. 

Payment Banks 

Each Payment Bank will have at least one account within the GPM System. A Payment 
Bank account will be identified by its BIG code, although the same entity may have other 
accounts as a User. Banks may have multiple accounts as Payment Banks so long as each is 
associated with a different BIG code (e.g., where the bank has branches participating in different 
domestic payment systems worldwide), 

GPM operations personnel shall issue, modify and manage Payment Bank account 
creation^ deletion and security features, including user logins, passwords, and authorisation 
verification procedures in connection witti access privileges for each employee within a Payment 
Bank. 

Payment Bank connection to the GPM System will also make use of global digital 
certification. Each Payment Bank will require issuance of a digital certificate as part of the 
acceptance process. Each session with the GPM System thereafter will begin with verification of 
the digital certificate details with the digital certification authority. 

Payment Bank details necessary for the management and billing will be stored on the 
GPM Data Server. These details will include, but are not limited to account name, company 
name, contact name, address, telephone number, facsimile number, e-mail address, account 
number, billing information, and communication information. 

All Payment Bank access will be protected through a Payment Bank-based 
access/entitlement security mechanism including digital certification. Only properly authorised 
Payment Bank employees will have the ability to instigate GPM System actions, including 
management of User relationships, creating or altering report formats, and generatmg 
notifications, messaging, inquiries, and other system actions. 
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On an ongoing basis, the GPM System maintains records of Payment Bank access and 
usage of the GPM System, and Payment Banks will have access to these records by way of 
inquiry and report facilities. 

Creating Counterparty Risk Parameters Within the GPM System 

Counterparties can be any entity with whom the User or Third Party has regul^ payments 
flows. Where a counterparty is not itself a participant m the GPM System, the counterparty will 
nonetheless be identified to the system by its BIC or UID. 

The definition of counterparties will be an important element in risk control, as affiliated 
entities might be aggregated as a single counterparty for risk management purposes, even where 
each entity trades for its own account (e.g., geographically diverse branches of a single bank). 
The User will be able to define a counterparty for its own purposes as an aggregation of UIDs 
and/or BICs. 

The GPM System of the illustrative embodiment facilitates flexibility in creating and 
modifying counterparty risk parameters for use in the GPM System. Where a User elects human 
interaction, he can manually enter Risk Parameters via a browser interface to the User Host 
Application. Alternatively, he may translate a spreadsheet file into a file consistent with User 
Host Application formatting requirements. For fully automated processing, the User may have 
an application-to-application interface which automatically generates counterparty risk 
parameters for the GPM System from data and processes in his internal back-office systems. 

Where a User is setting coxmterpaity risk parameters manually, they would select a 
counterparty fi-om a drop-down list on the screen (with an option to add a new counterparty). On 
the next screen they would be presented with a table of currencies (with an option to add or 
delete particular currencies) and spaces for Clean Payment Limit. 

The User can set counterparty pareimeters either by sending an individual instruction for a 
counterparty on-Une, or by way of file upload at any time durmg a session. 

Instances of tiie User Host Application for application-to-application interface may 
include a periodic automated initiation of connection to the GPM Core System with fully 
automated upload of data files for risk parameters. 

GPM Filter Process Module Processing 
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The GPM System stores received data and messages from Users in the GPM Core 
System Data Server. The data and messages are validated for syntax and field validation. The 
Process Server then analyses the data, sorting counterparty instructions in the first instance 
according to tihie BIC of the Payment Bank, The data is then compiled for transmission to the 
Payment Bank Host Application. 

The Payment Bank Host Application is configured to accept counterparty risk parameters 
as parameters for rule-based decisions in the Filter Process Module on whether to permit 
individual payments messages to proceed for payment to the domestic payment system or return 
the payment message back to the payment queue held on the Payment Bank's internal systems. 
Where a payment complies with risk parameters, it will be allowed to proceed for payment. 
Where a payment would breach the parameters, it is retumed to the payment queue for later 
reassessment. 

The Filter Process Module is acting in real-time to control User risk vis-a-vis the 
counterparty. It does this by using the data captured from incoming payments from the 
counterparty and outgoing payments to the coxmterparty to update the Available Balance 
calculated withm the Filter Process Module about payment flows. Payments from a 
Counterparty (e.g., reflected in the generation of an MT 910) add to the Available Balance for 
outgoing payments. Outgoing payments (e.g., reflected in the generation of an MT 900) detract 
from the Available Balance. Because the payments messages use standard data formats and 
identifiers for banks and account holders, these data fields can be captured and interpreted 
consistently to populate the calculations in the Filter Process Module in conformity with a large 
number of domestic payment systems. 

In the event that there are multiple Counterparties of a User for a given payment, 
preferably the Filter Process Module iteratively evaluates the given payment for compliance with 
the risk parameters applicable to each Counterparty as described above. 

The Payment Bank Host Application will maintain a log of payments activities. This will 
enable flexible compilation of reports on either a periodic or on-demand basis. At the end of the 
day, summary information about the day's activities will be transmitted to the GPM Core System 
as part of the log-off process. 

Exceptions Processing 
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Where the Payments Bank Host Application has rejected payments to a particular 
coimterparty for some pre-defined period of time (e.g., half-hour), it will automatically generate 
a notification to alert the Payment Bank and the User to the potential problem. Either or both 
may then request a report of payments activities concerning the counterparty be generated by the 
Payment Bank Host Application. 

All payments messages, whether successful or rejected, will be cached to support 
inquiries about the nature and amount of rejected payments. 

Very often a User will want to initiate inquiries with a counterparty who has failed to 
make timely payment as expected. If the counterparty is also a User or Third Party withm the 
GPM System, the User receiving an exception notification can initiate an inquiry through on-line 
messaging to the User or Third Party. (Third Party messaging will be routed through the Third 
Party's designated User.) 

Overriding Payments Filter 

There may be mstances where a Payment Bank will wish to override the Payments Bank 
Host Application to enable a payment to proceed to the domestic payment system despite its 
failure to pass all risk parameters. If so, the Payment Bank will access the Payment Bank Host 
Application via a browser interface. It will identify the payment it wishes to act on fi-om the log 
of rejected payments. It can then instruct the Filter Process Module to override the parameters 
for that payment the next time it is processed, enabling the payment to go forward to the 
domestic payment system. 

Users and Third Parties will be able to instruct override of the Filter Process for 
mdividually specified payments, as identified by the Transaction Reference Number, or 
payments goit^ to particular counterparties or mtennediaries. The User or Third Party will 
access the appropriate host application via a browser interface. They will identify the payment 
for override, or the counterparty or intermediary, and send the instruction for override to the 
Payment Bank(s) Filter Process Module via the Core System. 

Suspending a Counterparty 

If on investigation the Third Party or User is mclmed to believe that a counterparty is in 
difficulty and at risk of default, or mdeed is subject to an msolvency action, the Third Party or 
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User may wish to suspend further payments in order to reduce any credit exposure to the 
counterparty. To do this the Third Party or User will access the browser interface for the Third 
Party or User Host Application, bring up the counterparty from a drop down list, and click on a 
button for "suspend payments". This button will lead to a screen displaying all the currencies 
dealt with for that counterparty. The Third Party or User then has the option of selecting 
individual currencies or pressing a button for "select all". Once the currencies are selected 
according to the User's discretion, he will click a button labeled "send Suspend Instruction". He 
will be asked to confirm whether he really wants to suspend fiirther payments to the 
counterparty, with a yes or no option. If he clicks the "yes" button, the instruction to suspend 
payments will be sent to all Payment Banks acting for tiie User. 

When the Payment Bank Host Application receives a Suspend Instruction referencing a 
counterparty, the Filter Process Module will automatically engage a trigger to reject further 
payments messages, regardless of compliance with risk parameters. The Payment Bank Host 
Application will generate a notification to the Payment Bank of the implementation of a Suspend 
Instruction. The Payment Bank still has the discretion to override the Payment Bank Host 
Application to release individual payments should it determuie to do so despite the effectiveness 
of the Suspend Instruction. 

Inqmries. Reports and Messaging 

Risk reduction and control are enhanced in the GPM System by the provision of flexible 
real-tune and periodic mechanisms for inquiries, reports and messaging. Any participant in the 
GPM System (Third Party, User or Payment Bank) will be able to send messages to any other 
participant in real-time, usmg standard e-mail capabilities integrated mto the GPM System. 
Inquiries can be structured as automated processes where the data sought by a User or Payment 
Bank can be obtained in an automated manner from the Payment Bank Host Application. 
Reports to participants on GPM System usage will be generated on an on-demand and periodic 
basis covering a variety of parameterised matters. These are likely to include: counterparty gross 
payments total, counterparty risk parameters, GPM risk reduction metrics, liquidity and 
efficiency of payments metrics, and other matters determined by the participants to be of interest. 
A periodic report of failed payment transactions will be generated a some prespecified time prior 
to the close of each domestic payment system, and will detail at this time the payment 
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transactions which have failed the Filter Process and remain on the payments queue within the 
Payment Bank. This will provide an opportunity to identify potential problems and their specific 
consequences, and to instruct overrides as appropriate to prevent undeskable payment failures. 
Participants will be able to structure reports to aggregate a variety of User accounts, Third Party 
accounts and counterparties, as required to form a consolidated view for their own risk 
m^agement and regulatory reporting needs. 

Audit Trail 

The GPM System will maintain a comprehensive audit trail within the GPM Core System 
Data Server of all system actions such that all actions can be reviewed for audit, regulatory and 
recovery purposes. The GPM Operations Workstation will be able to access the audit trail via 
the operator's browser interface to the system. 

Advantages of the Present Invention 

As shown in the graph of Fig. 10, the GPM System of the present invention provides 
simple and effective risk reduction with great advantages over all prior art systems hitherto 
known. The accompanying graph is an illustrative example of the effect of risk management as 
between two market counterparty Users of the GPM System of the present invention (although 
only one needs to use GPM for it to be effective). In this example. Party A and Party B have 
entered into a plurality of transactions throughout a trading day resulting in a portfolio of trades. 
The graph shows the gross amoimts which must be paid in settlement of these trades such that 
Party A must pay $55M worth of US dollars and $45M worth of Euro at market prices. Party B 
must pay $55M of Euro and $45M wortti of US dollars to settle its gross obligations under the 
same portfolio of transactions. (All amounts are measured in US dollars for convenience of 
reference.) As a result, each party must pay the gross amount of $1 lOM. In the current system, 
payments to this amount would be made without any assurance of receiving the counterpayments 
of $1 1 OM value expected from the counterparty to the transactions. As a result, each party 
would undertake payment risk and liquidity risk of $1 lOM on the other for that day's settlements. 

Under the GPM System of the present invention, however, each party sets his own Clean 
Payment Limit for each currency. In this example. Party A has set the Clean Payment Limit in 
US dollars at $10M, while Party B has set it lower at $3M. Party B's risk on Party A is therefore 
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lower than Party A's risk on Party B, consistent with individiial risk assessment and the extent of 
the payment obligations. In Euro, Party B has set his Clean Payment Limit at $10M, consistent 
with his net payment obligation, and Partj^ A has set his Clean Payment Limit at $2M, perhaps 
reflecting the greater diflBculty of financing liquidity in Euro rather than a poor assessment of 
Party B's credit. The total payment risk for each party is reduced to their net payment obligation 
in the sold currency and the Clean Payment Limit in the bought currency. (The real measure may 
well be substantially less if the amount of the Net Payment Limit has been offset by receipts of 
payments in other payment systems in earlier time zones prior to a default.) In the illustrated 
example, the gross payment risk of $1 lOM has been reduced to $12M for Party A and $13M for 
Party B. 

The amounts set for Clean Payment Limits are within the discretion of Third Parties and 
Users, but some guidance and good practice are likely to emerge relatively quickly. As a rule, 
the Clean Payment Limit should equal or exceed the greater of the net payment amoxant in a 
currency (if any) or the smgle largest gross payment. If participants follow this guidance, then 
the GPM System will promote improved liquidity in payments systems by ensuring that 
payments liquidity flows to those making payments in a timely ^d sensible manner. 

The present invention also has significant advantages for efficient liquidity management, 
crisis management and information management. 

Other Uses and Modifications 

Many aspects of the present invention relate to participant interface techniques for 
generating, storing, accessing and communicating information, data or messages which need not 
relate solely to payments or even financial transactions alone, but could relate to the contolled or 
balanced allocation of other resources. 

While the illustrative embodiment of the GPM System described above will have many 
applications to the financial industry, it is understood that various modifications thereto will 
occur to those with ordinary skill in the a^rt. However, all such modifications and variations are 
deemed to be within the scope and spirit of the present invention as defined by the accompanying 
Claims to Invention. 
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